Demographic analysis using time-based consumer transaction histories

ABSTRACT

Systems, apparatus, and methods for determining groups of similar consumers and for identifying a trend in consumer behavior are provided. Likelihoods of a transaction being initiated at various times by one consumer can be calculated based on previous transactions of the consumer. The likelihoods for different consumers can be used to determine a group of similar consumers as a demographic. The likelihoods of a transaction being initiated at various times by a consumer of a demographic (or other entity) can be used to forecast trends (such as a demand for a product) and make business decisions, such as for marketing campaigns, inventory levels (e.g. at particular stores or for all stores), pricing, and store locations. Such likelihoods when focused to a particular category of transactions can provide even greater accuracy.

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application claims priority from and is a non provisionalapplication of U.S. Provisional Application No. 61/175,381, entitled“SYSTEMS AND METHODS FOR DETERMINING AUTHORIZATION, RISK SCORES, ANDPREDICTION OF TRANSACTIONS” filed May 4, 2009, the entire contents ofwhich are herein incorporated by reference for all purposes.

This application is related to commonly owned and concurrently filedU.S. patent applications entitled “PRE-AUTHORIZATION OF A TRANSACTIONUSING PREDICTIVE MODELING” by Faith et al. (attorney docket number016222-046210US), “DETERMINING TARGETED INCENTIVES BASED ON CONSUMERTRANSACTION HISTORY” by Faith et al. (attorney docket number016222-046220US), “TRANSACTION AUTHORIZATION USING TIME-DEPENDENTTRANSACTION PATTERNS” by Faith et al. (attorney docket number016222-046240US), and “FREQUENCY-BASED TRANSACTION PREDICTION ANDPROCESSING” by Faith et al. (attorney docket number 016222-046250US),the entire contents of which are herein incorporated by reference forall purposes.

BACKGROUND

The present application is generally related to tracking and processingconsumer transactions, and more specifically to using a history ofconsumer activity in determining a demographic of consumers and trendsin transactions of a demographic.

As part of marketing campaigns for a product, companies have identifieda particular group of consumers that are likely to buy the product. Agroup of consumer is sometimes referred to as a demographic. Typically,a demographic is determined by external features of a consumer, such asage or geographic location. Although such demographics can be useful,other characteristics of consumers with a same age or location can varysignificantly. Thus, a marketing campaign or other business decisionbased on such demographics can be faulty due to conflicting data sincethe consumers have disperse characteristics. Moreover, such demographicstypically provide only very general information, and thus do not provideinformation for making specific business decisions.

Therefore, it is desirable to provide better methods of identifyinggroups of consumers and for providing more detailed information aboutthe transactions of a group of consumers.

BRIEF SUMMARY

Embodiments provide systems, apparatus, and methods for determininggroups of similar consumers and for identifying a trend in consumerbehavior. Certain embodiments can use likelihoods of a transaction beinginitiated at various times to determine a group of similar users as ademographic (affinity group). The likelihoods at a plurality of timescan be used to forecast trends (such as a demand for a product) and makebusiness decisions, such as for marketing campaigns, inventory levels(e.g. at particular stores or for all stores), pricing, and storelocations. Such likelihoods when focused to a particular category oftransactions (e.g. a particular product) can provide even greateraccuracy.

According to one embodiment, a method of identifying a consumer asbelonging to a particular demographic is provided. Data respectivelyassociated with transactions of a first entity and one or more secondentities are received. A computer system identifies patterns of thefirst entity and patterns of the second entity. Each pattern includes aplurality of values, with at least two of the values respectivelyincluding contributions from transactions corresponding to differenttime ranges. Whether the first entity and the one or more secondentities belong to a same demographic is determined based on acomparison of patterns of the first entity and the second entities.

According to another embodiment, a method of identifying a trend inconsumer behavior is provided. Data associated with previoustransactions of an entity are received. A computer system determines oneor more patterns of the previous transactions. Each pattern includes aplurality of values, with at least two of the values respectivelyincluding contributions from transactions corresponding to differenttime ranges. Likelihoods for an occurrence of a transaction aredetermined according to the one or more patterns. Each likelihood is forthe occurrence of the transaction at a respective one of a plurality ofdifferent times. A trend in occurrences of the transaction is identifiedbased on the likelihoods at the plurality of different times.

Other embodiments of the invention are directed to systems, apparatuses,portable consumer devices, and computer readable media associated withmethods described herein.

A better understanding of the nature and advantages of the presentinvention may be gained with reference to the following detaileddescription and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a system according to an embodiment ofthe present invention.

FIG. 2A shows a plot of a transaction history or other events of a firstconsumer as analyzed according to embodiments of the present invention.

FIG. 2B shows a plot of a transaction history or other events of asecond consumer as analyzed according to embodiments of the presentinvention.

FIG. 3 is a flow chart of a method 300 for identifying a consumer asbelonging to a particular demographic and identifying a trend inconsumer behavior using a demographic according to embodiments of thepresent invention.

FIG. 4 is a plot of a number of transactions at certain elapsed timesbetween a final transaction (with key KF) and an initial event (with keyKI) of a correlated key pair according to embodiments of the presentinvention.

FIG. 5A shows a table that stores time information for a key pair<KI:KF> according to embodiments of the present invention.

FIG. 5B shows a plot for use in determining the time ranges for tableaccording to an embodiment of the present invention.

FIG. 6 shows an example of obtaining indicia of a similarity oftransactions of one entity relative to a transaction pattern of anotherentity according to embodiments.

FIG. 7 shows a calculation of a likelihood that transaction patterns ofa first entity are similar to transaction patterns of a second entityaccording to embodiments.

FIG. 8 is a flowchart of a method for determining a likelihood of atransaction and using the likelihood to identify a trend according toembodiments.

FIG. 9 shows a block diagram of an example computer system usable withsystems and methods according to embodiments of the present invention.

DETAILED DESCRIPTION

Information about a group of consumers can be useful in making businessdecisions (such as shaping marketing decisions or inventory levels).However, consumers have typically been organized by broad externalfactors like age. Embodiments can provide more narrowly tailoredaffinity groups, e.g., ones that have similar transaction patterns. Suchaffinity groups can lead to greater accuracy in determining success of abusiness decision. Likelihoods of a transaction at various times canalso be used to identify trends in certain types of transactions, andtherefore allow accurate forecasting.

I. System Overview

FIG. 1 shows an exemplary system 20 according to an embodiment of theinvention. Other systems according to other embodiments of the inventionmay include more or less components than are shown in FIG. 1.

The system 20 shown in FIG. 1 includes a merchant 22 and an acquirer 24associated with the merchant 22. In a typical payment transaction, aconsumer 30 may purchase goods or services at the merchant 22 using aportable consumer device 32. The merchant 22 could be a physical brickand mortar merchant or an e-merchant. The acquirer 24 can communicatewith an issuer 28 via a payment processing network 26. The merchant 22could alternatively be connected directly to the payment processingnetwork 26. The consumer may interact with the payment processingnetwork 26 and the merchant through an access device 34.

As used herein, an “acquirer” is typically a business entity, e.g., acommercial bank that has a business relationship with a particularmerchant or an ATM. An “issuer” is typically a business entity (e.g., abank) which issues a portable consumer device such as a credit or debitcard to a consumer. Some entities can perform both issuer and acquirerfunctions. Embodiments of the invention encompass such single entityissuer-acquirers.

The consumer 30 may be an individual, or an organization such as abusiness that is capable of purchasing goods or services. In otherembodiments, the consumer 30 may simply be a person who wants to conductsome other type of transaction such as a money transfer transaction or atransaction at an ATM.

The portable consumer device 32 may be in any suitable form. Forexample, suitable portable consumer devices can be hand-held and compactso that they can fit into a consumer's wallet and/or pocket (e.g.,pocket-sized). They may include smart cards, ordinary credit or debitcards (with a magnetic strip and without a microprocessor), keychaindevices (such as the Speedpass™ commercially available from Exxon-MobilCorp.), etc. Other examples of portable consumer devices includecellular phones, personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The portable consumer devices can also be debit devices (e.g., adebit card), credit devices (e.g., a credit card), or stored valuedevices (e.g., a stored value card).

The merchant 22 may also have, or may receive communications from, anaccess device 34 that can interact with the portable consumer device 32.The access devices according to embodiments of the invention can be inany suitable form. Examples of access devices include point of sale(POS) devices, cellular phones, PDAs, personal computers (PCs), tabletPCs, handheld specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike.

If the access device 34 is a point of sale terminal, any suitable pointof sale terminal may be used including card readers. The card readersmay include any suitable contact or contactless mode of operation. Forexample, exemplary card readers can include RF (radio frequency)antennas, magnetic stripe readers, etc. to interact with the portableconsumer devices 32.

The access device 34 may also be a wireless phone. In one embodiment,the portable consumer device 32 and the access device are the samedevice. For example, a consumer may use a wireless to phone to selectitems to buy through a browser.

When the access device 34 is a personal computer, the interaction of theportable consumer devices 32 may be achieved via the consumer 30 oranother person entering the credit card information into an application(e.g. a browser) that was opened to purchase goods or services and thatconnects to a server of the merchant, e.g. through a web site. In oneembodiment, the personal computer may be at a checkout stand of a retailstore of the merchant, and the application may already be connected tothe merchant server.

The portable consumer device 32 may further include a contactlesselement, which is typically implemented in the form of a semiconductorchip (or other data storage element) with an associated wirelesstransfer (e.g., data transmission) element, such as an antenna.Contactless element is associated with (e.g., embedded within) portableconsumer device 32 and data or control instructions transmitted via acellular network may be applied to contactless element by means of acontactless element interface (not shown). The contactless elementinterface functions to permit the exchange of data and/or controlinstructions between the mobile device circuitry (and hence the cellularnetwork) and an optional contactless element.

The portable consumer device 32 may also include a processor (e.g., amicroprocessor) for processing the functions of the portable consumerdevice 32 and a display to allow a consumer to see phone numbers andother information and messages.

If the portable consumer device is in the form of a debit, credit, orsmartcard, the portable consumer device may also optionally havefeatures such as magnetic strips. Such devices can operate in either acontact or contactless mode.

Referring again to FIG. 1, the payment processing network 26 may includedata processing subsystems, networks, and operations used to support anddeliver authorization services, exception file services, and clearingand settlement services. An exemplary payment processing network mayinclude VisaNet™. Payment processing networks such as VisaNet™ are ableto process credit card transactions, debit card transactions, and othertypes of commercial transactions. VisaNet™, in particular, includes aVIP system (Visa Integrated Payments system) which processesauthorization requests and a Base II system which performs clearing andsettlement services.

The payment processing network 26 may include a server computer. Aserver computer is typically a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The payment processing network 26 may use any suitable wiredor wireless network, including the Internet.

As shown in FIG. 1, the payment processing network 26 may comprise aserver 26 a, which may be in communication with a transaction historydatabase 26 b. In various embodiments, a transaction analyzer 26 c candetermine patterns in transactions stored in transaction historydatabase 26 b to determine certain actions, such as authorizing atransaction or sending an incentive. In one embodiment, an incentivesystem 27 is coupled with or part of payment processing network 26 andcan be used to determine an incentive based on determined transactionpatterns. Each of these apparatus can be in communication with eachother. In one embodiment, all or parts of transaction analyzer 26 cand/or transaction history database 26 b may be part of or sharecircuitry with server 26 a.

As used herein, an “incentive” can be any data or information sent to aconsumer to encourage a transaction. For example, a coupon can be sentto a consumer as an incentive since the consumer can obtain a bettertransaction price. As another example, an advertisement can be sent to aconsumer to encourage a transaction by making the consumer aware of aproduct or service. Other example of incentives can include rewards formaking a transaction and preferential treatment when making thetransaction.

The issuer 28 may be a bank or other organization that may have anaccount associated with the consumer 30. The issuer 28 may operate aserver which may be in communication with the payment processing network26.

Embodiments of the invention are not limited to the above-describedembodiments. For example, although separate functional blocks are shownfor an issuer, payment processing network, and acquirer, some entitiesperform all or any suitable combination of these functions and may beincluded in embodiments of invention. Additional components may also beincluded in embodiments of the invention.

II. Transaction Patterns and Demographics

Consumer activity can include transactions, among other things.Knowledge of a pattern of transactions of a consumer can allowidentification of consumers with similar transaction patterns. Patternsof transactions can also allow identification of similar merchants, orother entities. The similar consumers can be identified as belonging toa demographic, also called an affinity group. Transaction patterns of ademographic can also be used to forecast business decisions for acompany who has customers from the determined demographic. However, theidentification of a pattern can be difficult given the enormous amountof data, some of which might exhibit patterns and some of which may not.

As used herein, the term “pattern” refers broadly to a behavior of anyset of events (e.g. transactions) that have a likelihood of repeating.In one aspect, the likelihood can be greater than a random set ofevents, e.g., events that are uncorrelated. The likelihood can beexpressed as a probability (e.g. as a percentage or ratio), a rank (e.g.with numbers or organized words), or other suitable values orcharacters. One type of pattern is a frequency-based pattern in whichthe events repeats with one or more frequencies, which may bepredefined. To define a pattern, a reference frame may be used. Invarious embodiments, the reference frame may be or include an elapsedtime since a last event (e.g. of a type correlated to the currentevent), since a beginning of a fixed time period, such as day, week,month, year, . . . (which is an example of a starting event), before anend of a fixed time period, or before occurrence of a scheduled event(an example of an ending event). Another event can be certain actions bythe consumer, such as traveling to a specific geographic location orbrowsing a certain address location on the Internet.

FIG. 2A shows a plot 200 of a transaction history or other events of afirst consumer as analyzed according to embodiments. Plot 200 showstimes at which each of a plurality of previous transactions 210 haveoccurred. As shown, time is an absolute time (e.g. date and time) or anelapsed time since an initial event 203. Herein, the term “time” canrefer to either or both a date and a time of a particular day. Theseprevious transactions 210, which occur before an end time 205, can beanalyzed to determine a pattern 220, which can be a function thatapproximates when the transactions are likely to occur. As an example,an identified pattern can be used to predict a likelihood of a nexttransaction, e.g. transaction 230.

Transaction patterns can also be used to determine whether consumers aresimilar, and thus whether they might be part of a same demographic. As asimple example, one demographic might be an pregnant woman or a newmother. Such consumers may have similar transaction patterns in buyingproducts for a baby. But such a demographic may not easily obtained fromage or other easily identifiable facts about a person. Also, certainconsumers may have similarities for which a cause may not be so easilyidentifiable. In these cases, a demographic may not even be known toexist.

FIG. 2B shows a plot 250 of a transaction history or other events of asecond consumer as analyzed according to embodiments. Plot 250 showstimes at which each of a plurality of previous transactions 260 haveoccurred. These previous transactions 260 can be analyzed to determine apattern 270.

The pattern 220 of the first consumer can then be compared to thepattern 270 of the second consumer. As shown, the pattern 220 is similarto the pattern 270. In one embodiment, the similarity can be based onvalue of the patterns at various times, e.g., a comparison of thelikelihood of a transaction at various times. In other embodiments,parameters of functions that define or approximate the pattern can becompared to determine if the patterns are similar. For example, afunction can be a linear combination of prescribed set of basisfunctions (e.g. sines and cosines) times corresponding coefficients,which may be compared.

In one embodiment, the second consumer is a demographic, and the pattern270 is a combination of patterns of consumers in the demographic. Insuch an instance, the number of occurrences of transaction may be quitelarger, but can be normalized to provide an accurate comparison.

The identification of a pattern can have many difficulties. If theprevious transactions 210 include all of the transactions of a consumerand exhibit only one pattern, then the identification of a pattern maybe relatively easy. However, if only certain types of transactions for aconsumer show a pattern, then the identification can be more difficult.Some embodiments can use keys (K1, K2, . . . ) to facilitate theanalysis of certain types of transactions, where a key can correspond toa type of transaction. A key can also allow identification oftransactions as being relevant for a current task (e.g. the key beingassociated with a transaction to be incentivized).

Adding to the complexity can be whether the path to a particulartransaction has an impact on the pattern, e.g., a pattern that existsonly when certain transactions precede or follow a transaction.Embodiments can store transaction data associated with a specific orderof keys (e.g. K1, K3). In this manner, the data for that specific ordercan be analyzed to determine the pattern. The order of keys also allowsthe further identification of relevant transactions.

All of this complexity can be further compounded in instances where acertain path (sequence of two or more transactions) can have more thanone pattern. Embodiments can use certain functional forms to helpidentify different patterns. In some embodiments, a combination ofperiodic functions are used, e.g., e^(−iwt), where w is a frequency of apattern. In one embodiment, the frequencies are pre-selected therebyallowing an efficient determination of the patterns. Further, thefrequencies can be identified by an associated wavelength, or wavelengthrange. Counters can be used for each wavelength range, thereby allowinga pattern to be very quickly identified by analyzing the values of thecounters.

III. Determining and Using Affinity Groups

FIG. 3 is a flow chart of a method 300 for identifying a consumer asbelonging to a particular demographic and identifying a trend inconsumer behavior using a demographic according to embodiments. In oneembodiment, previous transactions (e.g. 210) are used to determinewhether a first consumer is part of a demographic. In oneimplementation, transactions within a specific time period are analyzed,e.g., last year or all transactions before an end time. The transactionscan also be filtered based on certain criteria, such that only certaintypes of transactions are analyzed. The transaction history can includevalid and fraudulent transactions. All or parts of method 300 or othermethods herein can be performed by a computer system that can includeall or parts of network 26; such a system can include disparatesubsystems that can exchange data, for example, via a network, byreading and writing to a same memory, or via portable memory devicesthat are transferred from one subsystem to another.

In step 310, data respectively associated with transactions previouslyperformed by a first consumer and with transactions by one or moresecond consumers are received. In one embodiment, the one or more secondconsumers are already determined to be part of an affinity group. In oneaspect, the affinity group can be considered as single entity withtransaction patterns being for the entire group.

In one embodiment, the data in the transaction history database 26(b)can be received at a transaction analyzer 26(c) of system 20 in FIG. 1,which includes a processor that may be configured with software. Eachtransaction can have any number of pieces of data associated with it.For example, the data may include categories of an account number,amount of the transaction, a time and date, type or name of product orservice involved in the transaction, merchant name or code (mcc),industry code, terminal field (whether a card is swiped), and geographiclocation (country, zip code, . . . ). In one embodiment, a merchantcould be a whole chain or a particular store of a chain. In someembodiments, the transaction data can also include video and/or audiodata, e.g., to identify a person or a behavior of a person. Thetransaction data can be different for each transaction, including theaccount number. For example, the consumer can be identified with theaccount number and other account numbers of the consumer can be includedin the analysis of the behavior of the consumer.

This data can be used to identify a particular type of transaction. Inone embodiment, the data for a transaction is parsed to identify one ormore keys, which are used as identifiers for a particular transaction.In various embodiments, a key can includes parts of the transaction dataand/or data derived from the transaction data. A key could also becomposed of results from an analysis of a transaction, e.g., whether thetransaction is a card-present transaction or a card-not-presenttransaction could be determined from the transaction data and includedin the key. In one embodiment, a mapping module can perform the mappingof the transaction data to one or more keys.

A key can be composed of multiple pieces of data (referred to herein asa key element). A longer key has more key elements and may be a moreselective identifier of a type of transactions. Each transaction can beassociated with different keys, each with a different scope ofspecificity for characterizing the transaction.

In step 320, transactions are correlated with other transactions andevents. In one implementation, transactions of the first consumer areonly correlated with each other, and similarly for the transactions ofthe second consumers. In this manner, different transaction patterns canbe identified for different types of transactions, and for differententities. Other events (e.g. start or end of a day, week, etc.) can becorrelated to transactions as well. An event can also be a movement ofthe consumer from one state to another (e.g. from an at-home state to anon-vacation state). Different events can also be identified with keys.Herein, examples are used to described how keys are used to identifytransaction types, but other suitable methods can be used.

In one embodiment, pairs of correlated keys (e.g. a key pair <KI:KF>)are determined based on whether transactions associated with an initialkey (KI) are correlated with transactions with a final a final key (KF).A first (initial) event can be correlated with a later (final)transaction. The initial key and the final key may be the same ordifferent from each other. For example, a transaction at one merchantmay be correlated to a later purchase at another merchant, which mightoccur if the merchants are near to each other. In one embodiment, agroup of more than two keys could be correlated together, e.g. a groupof three keys can be correlated.

Two transactions can be correlated in multiple ways depending on howmany keys are associated with each transaction. Thus, two transactionscan contribute to more than one key pair, when the transactions areassociated with multiple keys. For example, if an initial transaction isassociated with two keys and the final transaction is also associatedwith two keys, then there could be four resulting key pairs. Also, atransaction may be correlated to another transaction only via certainkeys.

In one embodiment, the transactions of a group of consumers can all beanalyzed together to determine correlations of transactions havingcertain keys. Certain key pairs can be pre-determined for tracking. Forexample, a store may want to have transactions at a specific location(or all locations) tracked.

In step 330, a computer system identifies one or more first patterns ofthe transactions by a first consumer and one or more second patterns oftransaction by the one or more second consumers. The computer system canbe transaction analyzer 26(c), which can be a subsystem or oneapparatus. In some embodiments, a pattern can be defined by a set ofindicia, which can be a set of numerical values. The indicia can conveythe likelihood of a transaction as a function of time. For example,pattern 220 conveys that transactions are likely when the function has ahigher value. In one embodiment, each pattern includes a plurality ofvalues (e.g. likelihood values) with at least two of the valuesrespectively including contributions from transactions corresponding todifferent time ranges.

In one embodiment, pairs of correlated transactions (or other events)are used to determine a pattern, e.g., as times of final transactionsrelated to initial events. The times can be stored as an absolute timeand/or date for each transaction (e.g. in chronological order) ororganized as elapsed times for correlated events of certain key pairs.The elapsed time may be the time between a transaction with K1 and thenext transaction with K2 for the correlated <K1:K2> pair. Other data canbe stored as well, e.g. data not included in the keys, such as an amountof the transaction. The elapsed time can effectively equal an absolutetime if the initial event is the beginning of a time period.

In some embodiments, the time information is stored (e.g. in transactionhistory database 26 b) associated with the corresponding key pair. Forexample, a key pair identifier (e.g. a unique ID number) can beassociated with the stored time information. As examples of anassociation, a key pair identifier could point to the time information,the time information could be stored in a same row as the key pairidentifier, and the key pair identifier could be stored associated withthe pointer.

In other embodiments, the time information for the key pair <K1:K2> canbe stored in a database table that can be accessed with a querycontaining K1, K2, or the combination (potentially in the order ofK1:K2). For example, a search for K1 and/or K2 can provide theassociated identifiers. In one embodiment, a hash of each key of a pairis also associated with the key pair identifier, so that information foreach key can be indexed and found separately. For example, hashes of K1and K2 can be stored in a lookup table so the key pair identifiers (andthus the key pair information) can be easily found.

In one aspect, storing time information in association with certain keypairs can allow the time information for specific types of transactionsto be easily accessed. Also, such organization can provide easieranalysis of the data to identify patterns for specific key pairs. Theoccurrences of the transaction can then be analyzed (e.g. Fourieranalysis or other functional analysis) to identify a pattern of thetimes and dates of these transactions.

In step 340, the one or more first patterns are compared to the one ormore second patterns. In one embodiment, a respective first pattern iscompared to a corresponding (matching) second pattern. A matching secondpattern can be a pattern with an exact same key pair, or a similar keypair. In one implementation, patterns can be compared by comparingnumerical values of certain indicia of the patterns. In anotherembodiment, patterns that do not match are also determined andincorporated into the comparison.

In one embodiment, the indicia can be the likelihood of patterns atrespective times. In one implementation, the likelihood is for anytransaction by a consumer, and thus the entire transaction history canbe used. In another implementation, the likelihood is for a particularkey pair. When a particular transaction is being investigated, therelevant pattern can be found by querying a database using the key(s) ofthe particular key pair. In various embodiments, the indicia for alikelihood may be a number of transactions in a time range or theprobability (or other measure of likelihood) at a given point in time,e.g., as calculated from a value of the pattern function at the point intime.

In step 350, whether first and second consumers belong to samedemographic is determined based on the comparison. In one embodiment,corresponding pairs of indicia from two patterns can be subtracted fromeach other and compared to a threshold. In another embodiment,corresponding pairs of indicia from two patterns can be multiplied timeseach other and compared to a threshold. As mentioned above, non-matchingpatterns can also be used. In one aspect, more non-matching patterns cancorrespond to a lower similarity of the first consumer to the secondconsumers. In yet another embodiment, the first consumer can be similarto an affinity group (i.e. belong to a demographic) with varying degreesof similarity (e.g. by percentage of similarity).

In some embodiments, the indicia of the patterns can be input into amodeling function as part of the determination. In variousimplementations, the modeling function can be an optimization function(e.g. a neural network) or can be a decision tree (e.g. composed of IFTHEN logic that compares the indicia). In one embodiment, anoptimization function can be trained on previous transactions ofmultiple entities, and thus can determine how much a pattern of aparticular entity (e.g. a consumer, merchant, or affinity group) issimilar to a patter of another entity. In another embodiment, the numberof keys associated with the transaction relates to the number of inputsinto the modeling function. The relationship is not necessarilyone-to-one as similar keys (e.g. ones of a same category) may becombined (e.g. same key elements, but just different values), but theremay be a correspondence between the number of different types of keysand the number of inputs.

Other embodiments can determine a demographic in other ways. Forexample, a merchant affinity group can be determined by identifyingtransaction patterns for a certain set of stores, which can be groupedby merchant code. At least some of the consumer's transaction patternscan then be compared to the transaction patterns for a merchant affinitygroup. Consumers having patterns similar to the merchant affinity groupcan belong to a same consumer affinity group. As another example, aconsumer can be sent an incentive to buy a new product (e.g. music) froma coffee shop, when the consumer is next predicted to visit the coffeeshop to buy coffee. Once the consumer performs the transaction, theconsumer can be partially defined by a certain music demographicaccording to the fact that the consumer bought music and potentially toa more narrow demographic of the type of music. As yet another example,a consumer can then be sent an incentive for a transaction consistentwith a demographic to which the consumer may belong. The use ofincentive can be used to determine whether the person is actually partof the affinity group. If the person does not use the incentive, thenthe consumer is less likely to be part of the affinity group.

In step 360, likelihoods of transactions are determined according todemographic patterns at a plurality of times. For example, after ademographic has been determined, the transaction patterns of thedemographic can be used to determine the likelihood of a transaction ata plurality of times. The likelihood can be for transactions at anytime, e.g. in the past and/or in the future. In one embodiment, thetimes include at least two different time ranges.

In step 370, a trend in the pattern for transactions can be identifiedbased on likelihoods of transactions at the plurality of times. A trendcan be the change (increase or decrease) of a likelihood from one timeto another. In one embodiment, a trend can be identified by a likelihoodof a transaction being above an upper threshold or being below a lowerthreshold. In such instances, a high or low likelihood can indicate thatthe likelihood is different from an average or outside of an expectedrange, and thus a trend can exist. In one aspect, a likelihood of apattern can be integrated over time to determined an average level orrange of likelihood.

A trend can also be related to a change in a pattern calculated at onetime to a change in a pattern calculated at a different time. Forexample, transaction patterns for a demographic can be calculated atvarious times (e.g. periodically, such as every month). A patterncalculated at one month can be compared to the same pattern (e.g. samekey pair) calculated at another month. The change in the likelihood of atransaction at various times can be used to determine a trend. Forinstance, the likelihood of a transaction at a particular time may haveincreased and thus a trend can be detected. The amount of change can beused to forecast a likelihood even greater than the predicted likelihoodsince there is a trend higher. In one embodiment, three or more patternscalculated at different times may be used to determine whether a trendactually exists. For each calculation of a pattern, the specifictransactions being used to determine the pattern can change as newtransactions may have been received and old transactions can be dropped.

In one embodiment, a similar process can be performed for the entities,such as merchants and groups of similar merchants. Transaction patternsof one merchant can be compared to transaction patterns of anothermerchant to determine similar merchants. As an example, knowledge of asimilar merchant can be used to determine when fraud might occur at amerchant. Trends in transactions of a merchant can be used to determineinventory levels inventory levels (e.g. at particular stores or for allstores) and other business decisions based on forecasting.

IV. Analysis of a Pattern

If a pattern of when transactions occur is known, then the pattern canbe used to determine when transactions are likely, and thus determinedemographics and trends. For example, if a pattern (e.g. a pattern oftransactions associated with specific keys) for one or more previousmonths is known, embodiments can use this pattern to determine a patternfor a future month (e.g. for same month next year or for a next month).The patterns can be analyzed in numerous ways, and FIG. 4 describes someembodiments.

FIG. 4 is a plot 400 of a number of transactions at certain elapsedtimes between a final transaction (with key KF) and an initial event(with key KI) of a correlated key pair according to embodiments. Plot400 can be considered as a histogram. The X axis is elapsed time betweena final transaction and a correlated initial event. Any unit of time maybe employed, such as minutes, hours, days, weeks, and even years. The Yaxis is proportional to a number of transactions. Each bar 410corresponds to the number of transactions at an elapsed time. Each bar410 can increase over time as new transactions are received, where a newtransaction would have an elapsed time relative to a correlated initialevent. Note that more than one transaction-event pair can have the sameelapsed time.

In one embodiment, the X axis can have discrete times. For example, onlytransactions for each day may be tracked. Thus, if the initial event wasthe start of a month, then the number of discrete time periods wouldhave a maximum of 31 days. In such an embodiment, elapsed time valueswithin a certain range can all contribute to a same parameter, and bars410 may be considered as counters. For example, if the discrete timeswere by day, any two transactions that have an elapsed time of 12 dayssince a correlated KI event would both cause the same counter to beincreased. In one embodiment, these counters are the time informationthat is stored as mentioned above. In some implementations, the timeranges do not all have the same length. For example, the time rangescloser to zero can have a smaller length (e.g. just a few minutes) thanthe time ranges further from zero (e.g. days or months).

A pattern 420 can be discerned from the elapsed times. As shown, pattern420 has a higher value at elapsed times where more transactions haveoccurred. In one embodiment, pattern 420 could simply be the countersthemselves. However, in cases where the time intervals are not discreteor have a small range, bars 410 might have zero or low value at timesthat happen to lie between many transactions. In these cases, certainembodiments can account for transactions at a specific time as well astransactions at times that are close. For example, as shown, a functionrepresenting pattern 420 begins curving up and plateaus near the cluster460 of transactions to form a peak 430. In one embodiment, each timepoint of the function can have a value of a moving average of the numberof transaction within a time period before and after (or just one or theother) the time point. In other embodiments, function can be determinedfrom interpolation or other fitting method (e.g., a fit to periodicfunctions) performed on the counters.

Indicia of the pattern 420, e.g., the function values, can be analyzedto determine when a transaction is likely and when one pattern issimilar to another pattern. In one implementation, peaks of the pattern420 are identified as corresponding to times when a transaction islikely and troughs (e.g. 470) are identified as corresponding to timeswhen a transaction is unlikely, both of which can correspond to a trendin the pattern. In one embodiment, a width of the function at specificvalues or times may then be used as a time window for identifying atrend. For example, a time window (e.g. a two day or 1.5 day period) ofwhen transactions often occur (or generally do not occur) may bedetermined. The time window can be used, for example, to determine whenand for how long inventory levels should be increased or decreased.

In one embodiment, a full width at half maximum may be used, such as thewidth of peak 430. In another embodiment, the window (e.g., 440) above athreshold value 450 is used, or just part of this window, e.g., startingat the time where pattern 420 is above the threshold and ending at thetop (or other part) of peak 430. In yet another embodiment, the timewindow may have a predetermined width centered or otherwise placed (e.g.starting or ending) around a maximum or other value above a threshold.

In embodiments using a threshold, the value of the pattern function maybe required to be above the threshold value before a transaction isconsidered likely enough to be related to a trend. As mentioned above,multiple threshold levels can be used, e.g., a lower and upper thresholddefining a range outside of which a likelihood value can be identifiedwith a trend. The use of thresholds encompass using the exact likelihoodvalues, which can be equivalent to using many threshold levels. Themodeling function mentioned above may be used to perform any of thesedeterminations.

In one embodiment, a threshold determination could be whether a counterhas a high enough value (absolute or relative to one or more othercounter). In another embodiment, a threshold level can be relative (e.g.normalized) compared to a total number of transactions. A normalizationor determination of a threshold can be performed by adjusting the leveldepending on the low values of likelihood of a pattern, e.g., a peak totrough height could be used. In one aspect, the troughs may be offset tozero.

Storing time information that includes a number of transaction atcertain elapsed times, one can not only handle paths (such as initialkey to final key), but one can also easily identify multiple patterns.Each peak can correspond to a different pattern. For example, each peakcan correspond to a different frequency of occurrence for a transactionassociated with the final key relative to an event (e.g. a transaction)associated with the initial key. In one embodiment, the time informationfor the elapsed times can be stored by storing a time of when bothevents occur. In another embodiment, time information can store theelapsed time as one value. In yet another embodiment, the time of oneevent might implicitly include the time of the initial event (e.g. whenthe first event is beginning of a month or other fixed time period).

From FIG. 4, one can identify one predominant pattern (peak 430) with along wavelength (short frequency), which does not occur very often, andthree minor peaks with higher frequencies. However, the determination ofa pattern might still take significant computational effort if thepattern can have any functional form.

V. Use of Periodic Functions and Counters

Some embodiments use certain functional forms to help identify differentpatterns. As mentioned above, periodic functions can be used, e.g.,e^(iwt), where w is a frequency of the pattern. For example, each bar(counter) 410 of FIG. 4 can correspond to a different frequency. Thetotal probability V of a K2 transaction occurring at a time t after a K1transaction can be considered as proportional to

${\sum\limits_{W}{C_{w}^{\; {wt}}}},$

where C_(w) corresponds to the counter value at the frequency w and wruns over all of the frequencies. C_(w) can be considered a coefficientof the periodic function e^(iwt) at a particular frequency. Thus,conceptually, a probability can be calculated directly from the aboveformula.

In one embodiment, the frequencies are pre-selected thereby allowing anefficient determination of the patterns. Further, the frequencies can beidentified only by the associated wavelength, or wavelength range. Notethat in certain embodiments, the use of e^(iwt) is simply a tool and theactual value of the function is not determined.

FIG. 5A shows a table 500 that stores time information for a key pair<KI:KF> according to embodiments of the present invention. The table 500stores information for elapsed times between transactions associatedwith the particular key pair. Table 500 can also store amountinformation for the transactions. Table 500 can be viewed as a tabularform of plot 400 along with all the possible variations for differentembodiments described for plot 400.

In one embodiment, each column 510 corresponds to a different timerange. The time range may correspond to ranges mentioned above withreference to FIG. 4. As shown table 500 has 6 time ranges, but anynumber of time ranges may be used. The time ranges can be considered tocorrespond to different functions that approximate the transactionpatterns of a consumer or other entity. For example, each time range cancorrespond to or be considered a different frequency w for e^(iwt).

In some embodiments, table 500 only has one row. In other embodiments,the rows of table 500 correspond to different dollar amounts (or dollaramount ranges). Thus, each time range may have subgroups for set rangesof amounts (e.g. dollar amounts). The organization is similar to amatrix, where a row or a column can be viewed as a group or subgroup.Although five amount ranges are shown, table 500 can have any number ofdollar amounts. In some embodiments, there is only one row. i.e. whendollar amounts are not differentiated. Note that the convention of rowand column is used for ease of illustration, but either time or amountcould be used for either row or column (each an example of an axis).Also, the data for a table can be stored in any manner, e.g. as a singlearray or a two-dimensional array.

The values for the matrix elements 520 correspond to a number of KFtransactions that have elapsed times relative to a KI event (e.g. atransaction) that fall within the time range of a particular column 510.In one embodiment, each newly received K2 transaction can cause a box(element) 520 of the table (matrix) 500 to be increased. The value ofthe matrix element (an example of a likelihood value) can be incrementedby one for each transaction, or another integer or non-integer value.The value can also be a complex number, as described below. In anotherembodiment, a table can be required to have a certain total of allvalues, average of the values, minimum value in any matrix element, orother measure of the values in the table. Such a requirement can ensurethat enough data has been received to provide an accurate pattern.

The values of the matrix elements can be used to determine the patternfor the key pair <KI:KF>, e.g. as part of step 330 of method 300. Forexample, matrix elements with high values relative to the other matrixelements can indicate a pattern of transactions in the correspondingtime range, which can correspond to a particular frequency w. In anotherembodiment, one could view each matrix element in isolation to determinewhether a transaction is likely. For example, if a matrix elementexceeds a threshold value, it may be determined that a transaction islikely to occur in that time range. The threshold can be determined invarious ways, for example, as a function of a sum of all of the matrixelements, or equivalently can be fixed with the matrix elements beingnormalized before a comparison to a threshold. Thus, step 330 can beaccomplished easier based on how the time information is stored.

As mentioned above, the time ranges can all be of the same length (e.g.24 hours) or be of varying lengths. In one embodiment, the first columnis of very short time length, the second column is of longer timelength, and so on. In this manner, more detail is obtained for shortwavelengths while still allowing data to be stored for long wavelengthswithout exhausting storage capacity. In another embodiment, dollaramount ranges are progressively structured in a similar manner as thetime ranges can be. In one implementation, the dollar amount range canbe used to track the likelihood of transactions having certain dollaramounts.

FIG. 5B shows a plot 510 for use in determining the time ranges fortable 500 according to an embodiment of the present invention. The Xaxis corresponds to the column numbers. The Y axis corresponds to thetime of a particular column in minutes. For example, the first columnincludes times between the first data point at time domain zero and thedata point at time domain 1. Due to the large scale of the Y axis, thesecond data point appears to be at zero, but is simply quite smallrelative to the maximum value.

The wavelength λ of a pattern corresponds to the time range of a column.For embodiments, using time relative to another transaction, then the λis the time between transactions. In one embodiment, 16 time domains(ranges) are selected as follows: λ_(o) is under 1 minute, λ_(I) isbetween 1 minute and 2.7 minutes, λ₂ is between 2.7 minutes and 7.4minutes, λ₃ is between 7.4 minutes and 20 minutes, and λ₁₅ is over 1.2million minutes.

The amount values can also be used to determine patterns fortransactions of certain dollar amounts. If the amount is not of concern,then the values in a column can be summed to get a total value for acertain time range. The amounts can also be incorporated into themathematical concept introduced above. For example, in mathematicalnotation, a value function can be defined as

${V = {\sum\limits_{W}{C_{w}A\; ^{\; {wt}}}}},$

where A is an amount of a transaction.

When a transaction is received, the amount and corresponding elapsedtime for a particular key pair can be used to determine a correspondingmatrix element for the key pair table. The values in the matrix elementscan be normalized across one table and across multiple tables. Forexample, a value can be divided by a sum for all the values of aparticular key pair table. Also, a sum can be calculated for all valuesacross multiple tables, and the values for each table divided by thissum. As part of a normalization, the value for a matrix element may bedecreased when some of the data used to determine the value becomes tooold. For example, for a time range that includes short time intervals,counts from transactions that have occurred more than a year ago may bedropped as being out of data since short timeframe patterns can changequickly.

In various embodiments, tables for different key pairs can havedifferent time ranges and/or amount ranges. If such differences dooccur, the differences can be accounted when a summing operation isperformed. In one embodiment, the values in the matrix elements can besmoothed to account for values in nearby matrix elements, e.g., in asimilar fashion as pattern 420.

In another embodiment, tables for different consumers can be compared todetermine affinity groups. For example, tables with matching or similarkey pairs can be subtracted (lower value more similarity) or multiplied(higher value more similarity). The closer the tables are, the moresimilarity (e.g. as a percentage) the consumers are, where non-matchingtables can be used for normalization. In one example, one set of tablescan correspond to the affinity group, and the calculation can be used todetermine whether a person is within the affinity group.

In other embodiments, specific amount ranges or time ranges can besuppressed. For example, if only certain types of patterns (e.g. onlycertain frequencies) are desired to be analyzed, then one can suppressthe data for the other frequencies. In one embodiment, the suppressionis performed with a mask matrix that has zeros in frequency columnsand/or amount rows to be suppressed. Thus, one can just multiply thematrices to obtain the desired data. The amount ranges can be similarlysuppressed. When suppressing certain frequencies, these mask matricescan act similarly to a high pass, low pass, or notch filters. Forexample, if one wanted a coupon to be good only for 7 days, and it takes1 day to create the coupon, the desired time window is any time rangethat includes those 6 days. Accordingly, the time information fortransactions outside the time window can be suppressed as not being ofinterest.

Regarding the creation and updating of such tables, after an event (e.g.a consumer transaction) is received, embodiments can determine whichtracked key pairs have finals keys that match with the keys resultingfrom the transaction. As a transaction can be associated with many keysand key pairs, a transaction may cause many tables to have a matrixelement updated. For example, the transaction may cause different tablesfor a specific consumer to be updated. The updates could be for onetable for all transactions by that consumer (an example of a generaltable), and more specific tables for particular zip codes, merchants,and other key elements. The transaction can also cause updates of tablesfor the particular merchant where the transaction occurred.

As there are different tables that can be updated, each with a differentinitial key, the time range (and thus the matrix element) that isupdated may be different for each table. For example, when elapsed timeis used, the last transaction for each table may be at a differentelapsed time since the different initial transactions. The transactionamount would typically be the same, thus the exact row for the matrixelement to be increased can be the same, as long as the tables have thesame amount ranges. But the column (i.e. time) could be different foreach table.

Regarding which time column to update, there can also be more than onecolumn updated for a particular table. For example, a K2 transaction mayhave different time patterns relative to K1 transactions (i.e., <K1:K2>pair). Accordingly, when a K2 transaction is received, elapsed timesfrom the last two, three, or more K1 transactions could be used toupdate the table.

In a similar manner, one key pair table could be <*:K2>, which includescorrelations from a plurality of initial keys to the K2 key in the sametable. Effectively, this table could equal the sum of all tables whereK2 is the final key for a particular consumer or other entity. However,if the individual key pairs are not significant enough, the <*:K2> tablemay be the only table that is tracked. Tables of the type <K1:*> couldalso be tracked.

VI. Impedance (Likelihood of Another Transaction)

Besides being able to predict when a particular transaction will occur,embodiments can also predict if another transaction is going to occurafter a current or a predicted transaction, which is referred to asimpedance. In some embodiments, such information can be tracked by usingcomplex numbers for the matrix elements of the final event, with theimaginary part corresponding to the impedance. In other embodiments, theimpedance can be tracked simply using another number for a matrixelement or using another table. In one embodiment, impedance values canbe used as indicia in the comparison of two patterns, e.g., to determinea demographic. In another embodiment, impedance values can be used todetermine to identify a trend. For example, if impedance values changefrom one time range to another that can signal a trend or if impedancevalues change from one calculation of a pattern to the next calculationof a pattern.

In such embodiments, the imaginary part of a matrix element cancorrespond to an impedance that measures how likely it is that anothertransaction will occur. Such values can be tracked for individualconsumers and/or groups of similar consumers (affinity groups). Thelikelihood can specifically correspond to a future transaction beingcorrelated to the current transaction having the time range and dollaramount of the matrix element. The real value of a matrix element cancorrespond to the probability that the KF event will occur, and theimaginary value can relate to the probability that another event will becorrelated to the KF event. The imaginary part can be updated whenanother transaction is correlated to the KF event of the specific timeand amount. In one embodiment, a table can have just one impedance valuefor the likelihood of any transaction occurring later. Thus, just oneimaginary part could be stored for an entire table. In anotherembodiment, the imaginary parts could be different for each matrixelement.

In an embodiment, a low impedance (e.g. a large negative imaginary part)for a matrix element means that there is a high probability that anothertransaction is going to occur, and a high impedance (e.g. high positivevalue) means that it is unlikely that another transaction is going tooccur, with zero being indeterminate. The implication of negative andpositive values can be swapped. In another embodiment, a high impedanceis provided by a low number (negative or positive), with larger numbersproviding low impedance, or vice versa. Certain future transactions canbe ignored (e.g. not counted) in determining impedance, for example, ifthe dollar amount is too low.

In one embodiment, the imaginary number can be tracked (e.g. increasedor decreased) in the following way. (1) When a KF event is received,each of the key pair tables that have the transaction as the endingevent are increased in real part of the appropriate matrix element, withan elapsed time measured from the respective starting event KI. (2) Foreach key pair table, the specific KI event to which KF was correlated isdetermined. Then for that KI event, each K0 event to which KI iscorrelated as a final event is determined, and the appropriate matrixelements of specific tables are determined using an elapsed time betweenthe specific KI and K0 events. (3) The imaginary part of the individualmatrix elements can then be adjusted (e.g. decreased to obtain a reducedimpedance) to reflect a higher likelihood that a another transactionfollows KI, since the KF event did indeed follow. If all of the matrixelements for a table have the same imaginary part, then the specific KIevent does not need to be known, just the tables that have the key foran ending KI need to be known, which can be determined with filtersoperating on the final keys.

In another embodiment, the imaginary part could be updated in a forwardmanner. (a) A KF event is identified. Each of the key pair tables thathave KF as the ending event are increased for the real part in theappropriate matrix element, with a KI event being the starting event. Inone aspect, KF might not have just come in, but could be part of a wholecollection of events being processed. (b) Then specific K2 final eventsthat correlate to the KF event as an initial event are identified. (c)Depending on the number of K2 transactions, the imaginary part of theappropriate matrix element can then be adjusted (e.g. increased,decreased, set, or reset). At this point, the imaginary part for justone matrix element (e.g. the matrix element from (a)) of tables for KFcould be determined. Or, all of the other matrix elements of the tablescould also be determined as well based on the value for the specificmatrix elements just determined. For example, all of the other matrixelements of a table can be updated to reflect that the K2 transactionoccurred. This can be done when all of the imaginary parts are the same,or if just one value is stored for an entire table.

In one embodiment, the default for the imaginary part can be set at zeroor some average value for a likelihood that a transaction occurs. Ifafter a certain amount of time, there are no transactions correlated toit, then the value might increase and continue to increase. Or thedefault could be set at a high impedance, and then lowered as moretransactions occur. In another embodiment, if the future transaction isfraudulent, then the complex part can also be changed to reflect ahigher impedance since a valid transaction does not occur. In anotherembodiment, if a decline occurs after a transaction then the impedanceis increased (e.g. the imaginary part is decreased by one), if anacceptance occurs after a transaction then the impedance is decreased(e.g. the imaginary part is increased by one).

In this way, one can determine the specific instances where thetransaction is a dead end (i.e. not leading to other transactions), andother instances where the transaction leads to other transactions. Ahigh impedance would convey that the transaction is a dead end as nofurther transactions occur very often. Conversely, one can determinethat a transaction is a gateway to many other transactions when it has alow impedance. In one embodiment, an average or sum of all of theimaginary parts of the matrix elements can be used to determine whetherany future transaction is likely.

Some embodiments can aggregate the imaginary part over all KI correlatedto a KF to determine a total likelihood that a KF will provide moretransactions. Thus, one can incentivize KF if the likelihood is high.Each of the tables with KF as the final event can be used to determineexactly when to send an incentive and what the incentive might be.

In one embodiment, one can see a dead end for one affinity group, butthen look at another affinity group that does not show this dead end. Ananalysis can then be made as to why the one group dead ends, andstrategy developed for causing the dead end not to occur (e.g. sending acoupon, pre-authorization, or other inventive). For example, one canidentify stores that the one affinity group does go to after thetransaction, and send coupons to that store. As another example, one canidentify stores geographically near a merchant that is a dead end andsend a coupon for a nearby store, even potentially for use within ashort time period after a predicted visit to the dead end merchant.After seeing if a strategy works by sending coupons to a couple peoplein an affinity group, coupons can be sent to more people in the affinitygroup (including people just partially in the affinity group).

Instead of or in addition to the above use of imaginary values forimpedance, greater impedance can also correspond to fraud. If a fraudtransaction K2 is found to correlate to a transaction K1, then the<KI:K1> matrix elements (or just a specific element) can have theimpedance increased. Thus, the impedance can reflect the profitabilityof the present transaction. For example, certain transactions happeningright after buying a concert ticket can be associated with fraud, whichis an example of where each matrix element may have its own complexpart.

In some embodiments, both real and imaginary parts of a matrix elementcan contribute to an overall value, which can be used to determinewhether a trend exists or patterns are similar. In other embodiments,values for the real or the imaginary components can be analyzedseparately to determine whether a trend exists or patterns are similar.

VII. Determination of Demographic

Once the relevant patterns (e.g. key pair tables resulting from afiltering process) are obtained for two entities, the patterns can becompared to determine indicia regarding a similarity between thepatterns. The indicia can be used to determine whether a person belongsto a particular demographic.

The calculation of the indicia can be performed in numerous ways. In oneembodiment, the indicia can include specific matrix elementscorresponding to a type of transaction. The matrix elements can bemodified (e.g. normalized) and/or summed to provide an overall indicia.In another embodiment, the indicia can result from an operationcombining values from patterns of the two entities. This sectiondescribes some embodiments for obtaining relevant indicia of alikelihood for an event from certain event patterns.

A. Determining Similarity of Transactions to Established Patterns

Whether a specific transaction or groups of transactions by one entityis similar to transaction patterns of another entity can be of interest.Such a similarity can be used to determine a demographic, which in turncan be used, for example, to predict transactions or authorize a currenttransaction. To determine a similarity, the current transaction can becompared to established transaction patterns. In an example where one ormore recent transactions are received, these recent transaction(s) canbe compared to established transaction patterns of other entities (e.g.a specific demographic).

FIG. 6 shows an example of obtaining indicia of a similarity oftransactions of one entity relative to a transaction pattern of anotherentity according to embodiments. In FIG. 6, a table 610 created fromfirst transactions of a first entity is multiplied (element by element)by table 620 of the other entity to provide indicia 630. Indicia 630 canprovide a measure of how similar the first entity (via table 1) is to asecond entity (via pattern table 620). A matrix element of the retrievedtable can provide a likelihood at a particular time directly or incombination with other values. For example, a matrix element can bedivided by a sum of matrix elements in a row, all matrix elements in atable, or all transactions of a person to determine a likelihood for therecent transaction.

In this simple example, suppose the first transactions are associatedonly with K1, and K1 is correlated only to K2. Then a table <K2:K1> canbe created with a number of transactions in the proper matrix elementsof table 610 relative to previous correlated K2 transactions. Table 610shows non-zero values for the first dollar amount and the fourth timerange, second dollar amount and second time range, and third dollaramount and fourth time range, with zeros in the other matrix elements.Then, matrix elements of table 610 can multiply the corresponding matrixelements of the <K2:K1> key pair table 620 (which has been matched andretrieved).

In one embodiment, the resulting indicia 630 is single value showing anoverlap between the tables. As shown, the result is 11*2, 8*7, 15*0, and6*0 equaling 78, which can be normalized later. The value of this matrixelement 630 can (e.g. when normalized) can provide a measure of alikelihood of similarity between the two entities. In this example, thelarger the value the higher the similarity. The more transactions thatoccur with a particular dollar and time in table 610 that correspond tonon-zero elements in table 620, the higher the resulting value, and thusthe patterns are more similar. In one aspect, the indicia can benormalized to account for the total number of transactions in bothtables, and thus a more accurate percentage of similarity can bedetermined. In another embodiment, all transactions with any dollaramount can be summed before multiplying, which would give 17*2, insteadof 11*2 and 6*0. The different embodiments might depend on the specificdemographic being investigated.

Overall, multiple tables of the first entity might result for a K1transaction. Also, multiple tables may be used in the comparison. Thevalues can be aggregated (e.g. summed) or analyzed separately todetermine a likelihood of similarity.

B. Multiplying Tables—Alignment

There may be instances where the key pair for a table of one entity isnot found in the key pairs of tables of another entity. When thisoccurs, a first table may be aligned with a second table to determine amatching table for multiplying. In one embodiment, a key for the firsttable can be broadened until a match occurs.

For example, a first table can have a final key of :4812,345>, where4812 is the merchant code and 345 is the first three digits of a zipcode. However, the tables of a second entity may not contain a tablewith this final key. This may be because the consumer has fewtransaction in zip codes starting with 345. But the first table maystill contain useful information as to a similarity of the entities.Thus, the key :4812,345> can be broadened to be :4812,*> so that itmatches with a table of the second entity. The zip code can be broadenedin one step or incrementally to :4812,34>, :4812,3>, and then :4812,*>,where a match is found.

Such alignment can be performed between sets of key pair tables. In ageneral sense, a set of key pair tables can be viewed as a key manifold.When the key manifolds are normal (i.e. both spaces have identicalamounts of keys), then one can apply the operations directly. However,if the key spaces are not normalized, then an alignment may beperformed.

In one embodiment, each table of one manifold is aligned with exactlyone table of the other manifold. In another embodiment, there may not bea match found for a table from one manifold to another. In such a case,the non-matching tables can be dropped, or distinguished from tablesthat did match after alignment. A distinction can also be made betweentables that only match after alignment and tables that match exactly.For example, it may be useful to know what the entities do that is notthe same (no match), or maybe just similar (match after some alignment).Also, other operations besides multiplication can be performed, such asdivision, subtraction, and addition.

C. Other Calculations of Likelihood

With this framework of aligning and multiplying keys, more complicatedcalculations of likelihood can be performed. Other operations, such asdivision can be used. A purpose of division can be to normalize a keymanifold (i.e. a set of tables).

FIG. 7 shows a calculation of a likelihood that transaction patterns ofa first entity are similar to transaction patterns of a second entityaccording to embodiments. Such a calculation can provide a likelihood ofoccurrence of a transaction. In various embodiments, first entity tables730 can be recently generated or previously generated and stored; andsecond entity tables 710 and total transaction tables 720 can be updatedat set times, e.g., once a day, week, etc. The constants table 740 is atable that can be used for normalizing, e.g., to place the values of atable to be within a specific range.

Second tables 710 can be obtained from transactions across multipleentities, thereby using a combined entity (e.g. an affinity group). Inone embodiment, the specific set of tables have a common key element,e.g., transactions for a specific merchant or during a specific month.Other key elements can be used, e.g., zip code, country, or any othersuitable key element.

Total transactions tables 720 can be obtained from all transactionsacross all or many entities. In one embodiment, the total transactionstables 720 are obtained from the same entities as tables 710. In anotherembodiment, the total transactions tables 720 are obtained from the sameentities as tables 710 and the first entity. Similar to second tables720, total transactions tables 720 can share a same key element, forexample, the same key element as in second tables 710. The totaltransactions can include fraudulent transactions and valid transactions,or just valid transactions.

Once the tables are aligned, the total transaction tables 720 can beused to normalize the second tables 710 by dividing a second table bythe corresponding total transaction table. After the division, thenormalized tables can be stored in RAM (or any other memory with fasteraccess than disk). As with FIG. 6, the division operation divides eachmatrix element of a second table with the corresponding matrix elementof the total transaction table. The division can provide a normalizationof the counters for the second tables. For instance, a particular secondtable may have high values in many matrix elements, but if there aremany total transactions, the total percentage of transactions for eachmatrix element can be low. The division can also account for anormalization of the first tables, or a separate normalization can beperformed on the first tables.

In one embodiment, each second table is aligned with exactly onetransaction table. For example, if there are 100 second tables tracked(i.e. for a given group having a common element, such as month), then100 tables result from the alignment and division. Note that thealignment can be implicit in the notation of a division operation. Insome embodiments, there may not be a match of a second table to a totaltransaction table, although this may happen rarely. In such a case, thesecond table may be dropped, and thus there may be fewer resultingtables than second tables. In an embodiment, one can differentiatesecond tables that do not have a match from tables that did match, orbetween tables that only match after alignment and tables that matchexactly.

First tables 730 can then aligned with the normalized tables. Beforealignment, some or all of the first tables can be summed. In oneembodiment, two first tables can be summed when the keys are similar. Ineffect, the final transactions for each of the tables can be consideredto be of a same type, i.e. have the same key. For example, if themerchant is the same, but the zip codes are different, the two tablescan be merged and the zip code dropped or broadened (which can beconsidered an intersection of the two key pair tables). This summing maybe particularly appropriate when both tables would be aligned with asame second table. In such a case, a summing after multiplying the firsttables by the normalized tables provides the same resulting table.

After alignment, the first tables can be multiplied element-by-elementwith the normalized tables, thereby providing a plurality of resultingtables. In one embodiment, these resulting tables can be summed toprovide one final table, or one final value. In one aspect, the summingcan be due to the second tables 710 being grouped to have a similar keyelement, and thus the final table can relate to the one key element.This final table can provide a measure of an overall similarity of thetransaction patterns, and can be used (e.g. by a modeling function) todetermine a likelihood of similarity. In another embodiment, each of theresulting tables can independently be final tables that are used by amodeling function.

In another embodiment, a mask matrix can be used to remove certainmatrix elements from the resulting tables or from the final table. Forexample, the mask matrix can remove low frequency or high frequencycomponents, or be a notch filter to select frequencies in the middle.Also, certain dollar amounts can also be removed. In one implementation,the mask matrix has 1s in matrix elements that are to be kept and 0s inmatrix elements that are not to be analyzed.

Although second tables 710 were normalized, the final table(s) may stillhave matrix elements with values that can vary widely. This variation invalues can cause instability in a modeling function, which uses thematrix element as indicia of the patterns to obtain a total likelihood.Accordingly, in some embodiments, constants matrix 740 is used toconstrain the final matrix element to be within a certain range ofvalues, e.g., between −1 and 1 or 0 and 1. In one embodiment, constantsmatrix 740 is created from a specified functional form, such as tan h,log, or sigmoid (generally S shaped) functional form.

Constants matrix 740 can also constrain matrix elements values tocorrespond to a third number within the prescribed range. For example, azero output can be mapped to a matrix element value where similarity maybe more difficult to determine and thus sensitivity needs to be greater.In one embodiment, the functional form of constants matrix 740 can bekept for an extended period of time, where inputs of specific matrixelement values (e.g. maximum and minimum values in a specific table) areused to determine the exact values. Which count corresponds to zero mayalso have an input parameter. The functional forms may be constant orvary across multiple entities.

The calculation shown in FIG. 7 can done for different groups of secondtables, e.g. one group shares a same merchant, one group shares a month,etc. In such embodiments, the first tables used for a particular groupcan be chosen to correspond with a particular group. Thus, differentfirst tables can be used for different groups. In one embodiment, eachof these calculations can then be combined and provided to a modelfunction that uses the inputs to determine whether a similarity exists,and potentially a level of similarity.

In one embodiment, the normalized tables (and potentially the firsttables) can be stored across multiple processors and each one canperform the corresponding multiplication if there is a match to an firsttable. As an alternative, a query can be provided to each processor andthe processor that is storing the desired second table can return therequested table. The final table(s) can be provided to a singleprocessor or set of processors that are configured to run a modelingfunction.

D. Subtraction of Matrices

Besides comparing different entities by multiplying their respective keymanifolds (sets of key pair tables), the manifolds can also besubtracted from each other. Each table (which can be normalized) can bealigned and the elements subtracted. If the difference is large, thenthe two manifolds are less likely to be part of the same affinity group.Embodiments can also analyze tables that do not match exactly, and onesthat match only after an alignment procedure. The values of thesematrices can be analyzed along with the differences for the tables thatdid match.

E. Representative Consumers

Beyond just tracking ones showing a correlation, the number of tablesbeing tracked for a consumer can be reduced in other ways. In oneembodiment, to reduce the number of tables, different zip codes of aconsumer could be considered the same. For example, a salesperson mighthave similar transaction history in cities on his/her route. All ofthese zip codes can be considered to be equivalent, and thus put intoone table. A similar treatment can be made for other key elements. Also,in a similar manner, different consumers can be treated as beingequivalent.

The knowledge of which affinity groups a consumer is similar can also beused to reduce the number of tables being tracked for a consumer. Asmentioned above, certain consumers can be grouped into affinity groups(demographics) in order to obtain more information about correlatedkeys. In one embodiment, the affinity groups may be used to define aconsumer. For example, if a group of consumers had identical orsubstantially similar transaction histories then separate tables do notneed to be stored. When a consumer of the affinity group made apurchase, the tables of the affinity group could be accessed.

Accordingly, the amount of total storage can be reduced by defining aconsumer by his/her affinity groups. Instead of storing the redundanttables for each consumer, just one set of tables can be stored. However,it may be uncommon for a consumer to have the same transaction patternsas a particular affinity group. In such cases, the consumer can bedefined as being a linear combination of affinity groups, which are eacha combination of key pairs. For example, there can be 100 affinitygroups AG. A consumer can be defined as 10% AG1, 15% AG 23, 30% AG 41,20% AG 66, and 25% AG 88. A consumer can also have individual tablesthat are used in combination with the affinity group tables.

A consumer can thus be viewed as a combination of representativeconsumers (affinity groups). Which representative consumers to use for aparticular consumer can be determined by sampling transactions of theconsumer. The sampling can be relatively small compared to the totaltransaction history that would be used if the consumer had his/her owntables. For example, the sample transaction of a consumer can show thathe/she has similar transactions to a certain demographic group. Thepercentage for each affinity group can be determined by a similarity inthe tables for the consumer relative to the affinity group.

In one embodiment, the similarity can be defined by taking thedifference between each of the matrices (tables) of the consumer fromeach of the matrices of the affinity group. Where a table exists for theconsumer, but not for the affinity group, a table of zeros can beassumed for the affinity group, and vice versa. As an alternative or incombination, an alignment mechanism (e.g. method 700) can be used toobtain more matches between the set of tables for the consumer and theset of tables for the affinity group.

In one aspect, tables for a consumer could be created initially untilone or more affinity groups are identified. Certain tables for aconsumer could still be kept to ensure that the transaction patterns donot change, thereby causing a need to reevaluate the specific linearcombination being employed. Thus, transaction data can be used todetermine which demographic a person fits into, as opposed todetermining what a demographic is based on similar consumers.

In one embodiment, if no transaction history is available for aconsumer, the consumer may be approximated using selected representativeconsumers. The selected representative consumers can be based onattributes, such as age or residence. In another embodiment, arepresentative consumer can be built for each zip code. Thisrepresentative consumer can be used as a default for a consumer livingin that zip code, at least until more information is obtained.

In another embodiment, a coupon can be used to probe a consumer todetermine if he/she belongs to a specific group. The coupon can be for acertain product and/or merchant that is highly correlated to a certainaffinity group. If the customer uses the coupon, then there is a higherlikelihood that the consumer is at least partially included thataffinity group.

VI. Determining Important Trends or Changes in Trends

To predict a likelihood of a future event, some embodiments can obtainthe relevant key pair tables for the entity (e.g. a consumer or ademographic) and then analyze these tables. Which tables are obtainedand how they are analyzed depends on exactly what events are trying tobe predicted, i.e. the question being answered. In some instances, onemay be interested in a particular transaction (e.g. a particular productor merchant) for marketing purposes. However, one generally may want toknow trends (a transaction pattern or changes in a transaction pattern)in consumer activity and changes in trends, but it may be difficult toidentify trends. Thus, automated ways to identify transaction patterns,potentially having specific features, and to identify patterns that arechanging can be provided.

FIG. 8 is a flowchart of a method 800 for determining a likelihood of atransaction and using the likelihood to identify a trend according toembodiments. For instance, patterns with high or low likelihoods can beused to determine a trend toward greater or fewer transactions. Changesbetween patterns can also be analyzed.

In step 810, data for one or more recent and/or upcoming events isreceived. In one embodiment, the event data (e.g. transaction data) isassociated with one entity, e.g., a particular consumer or affinitygroup. For recent events, whether an event is “recent” can be relativeto other events. For example, if an event does not occur often, a recentevent (e.g. a last event of that type) can still occur a long time agoin absolute terms. For an upcoming event, the event has not occurredyet, but can be known to occur. For example, the start of a month (orother time period) has a known time of occurrence. As another example, ascheduled event (such as a sporting event or concert) can be used. Datafor these scheduled events can be obtained before they occur due to thenature of these events. In one aspect, recent and/or upcoming events areused to identify patterns that may exist in the future as opposed topatterns that have existed previously.

In step 820, the event data is used to map each event to one or morekeys KI. In some embodiments, the mapped keys KI are specifically keysthat are being tracked for an entity. In step 830, tables of patternsthat have an initial key of KI are obtained, thereby providing <KI:tables relevant to the received event data. In one embodiment, amatching and retrieval function identifies the relevant tables usingmethods described herein. The matching and retrieval function can alsomatch tables that do not have the exact same key, but similar keys. Asimilar key can be a broader version (e.g. first 3 digits of a zip code)of a more specific key (e.g. 5 digit zip code). Examples of when suchalignment would be performed include: when a specific key for a currenttransaction is received, but only a broader version of that key is beingtracked; and when two entities are being compared and different keypairs are tracked. In embodiments where an event is an upcoming event,the upcoming event can be a final event (or effectively the time rangescan be negative with the upcoming event being an initial event), wheretransactions before the ending event are analyzed.

In step 840, the <KI: tables having matrix elements with sufficientlyhigh or low counts are identified, e.g., to determine KF events that canbe part of a trend. The trend may be a change in likelihood, which canbe identified when a count is outside of a band of expected or averagevalues. In one embodiment, to determine whether a matrix element has asufficient count, one or more absolute or relative threshold numbers canbe used (e.g. below a lower and above an upper bound). A relativethreshold (e.g. a percentage) could be determined using a total numberof counts for a table or group of tables. In another embodiment, alltables (i.e. not just ones with a matching KI for initial key) could beanalyzed to find matrix elements with high or low counts, therebyeliminating steps 810 to 830. However, using recent or upcoming eventscan provide greater timeliness for any result, or action to be performedbased on a result. The identified KF events along with the specific timeranges for the matrix elements with the high or low counts can then beanalyzed.

In step 850, other matrix elements not previously identified areobtained for each likely KF event. For example, a KF event can becorrelated to more initial keys than just the ones identified in step820. These previously unanalyzed tables can also have counts outside ofa band for certain matrix elements involving a KF event. The KF eventcan be used as a filter to identify unanalyzed tables, from which otherhigh or low count matrix elements can be obtained. Thus, this step canbe used to obtain a more accurate likelihood for a specific KF event.Obtaining these other matrix elements may not be needed, e.g., if KI isstarting event, such as a beginning of a week, month, etc. In this case,since other tables might include the same data points, these othertables could just include redundant information.

Also, other matrix elements for KF events can be important if highaccuracy is desired. For example, as the timeframes of the different:KF> tables can be different (due to different KI events), matrixelements having relatively average counts can correspond to the sametimeframe as a high or low count matrix element. Thus, the number ofcounts for a likely time range can be revised.

In this manner, high probability KF events can be determined based on afew recent or upcoming KI events, and then a full analysis of :KF>tables can be performed, as opposed to randomly selecting KF events todetermine when they might be likely to occur. A KF event could be chosenfor analysis, but a selected KF event might not be highly likely.However, if one were interested in a specific KF event, then it may bedesirable to start method 800 at step 850.

In step 860, the matrix elements (e.g., just from step 840 or also fromstep 850) are combined to obtain a probability distribution vs. time fora :KF> event, which is correlated to many <KI: events. In oneembodiment, each of the matrix elements for the KF event are combinedfrom a portion or all of the <KI:KF> tables, where KI runs over theinitial events that are correlated to the KF event. This combination canaccount for the fact that the different KI events occur at differenttimes, and thus the time ranges for each table can be different (e.g.offset).

In one implementation, the earliest or latest KI event can beidentified, and offsets for the time ranges of the other tables can bedetermined. The corresponding matrix elements can then be added usingthe offsets. If a time range of a matrix element of one table onlypartially overlaps an offset time range of another table, then thecombination can be broken up into more time ranges with proportionalcontributions from each previous rime range. For example, if two timeranges overlap, then three time sections can result. The overlap sectioncan receive contributions (i.e. a percentage of the counts) from the twomatrix elements, with the amount of contribution proportional to theamount of overlap in time for the respective time ranges.

To determine a time range of high likelihood, a probability distributioncan be created from the resulting time ranges X after the combinationand the counts Y for each time range. The resulting time ranges X withthe respective counts Y can be analyzed as a function Y=F(X), which cancorrespond to pattern 420 of FIG. 4. The Y values can be normalized sothat the counts for time ranges of different lengths are accounted. TheY values can also be normalized based on the dollar amount of atransaction.

In step 870, a trend is confirmed for a particular time or time window(e.g. time range of the identified matrix element) by analyzing theprobability distribution. In one embodiment, a total likelihood for a KFevent (e.g. across multiple initial events) can be calculated to confirmthat the likelihood is still outside the average or expected band.Likelihood values near the time range can also be examined to identifyregions of significant change in probability. A specific time window maycorrespond to a predetermined time range of a matrix element, or beanother time range that results from an overlap of multiple time ranges.For example, if two matrix elements overlap in time (e.g. because the KIevents occur at different times), then the time window may have therange of the overlap time. In one aspect, the trend can be for a one ormore specific amounts of the transaction, which can be selected bymultiplying with a mask matrix.

Besides confirming a time window, any new time windows related to atrend can be identified. To determine a time range of high or lowlikelihood, the probability function F can be analyzed. For example, thefunction F can be analyzed with a numerical routine to identify amaximum, minimum, or regions having values outside of a range. Toidentify maximum or minimum regions, techniques such as finitedifference, interpolation, finite element, or other suitable methods,can be used to obtain first and second derivatives of F. These derivatescan then be used in an optimization algorithm for finding a maximum.Global optimization methods can also be used, such as simulatedannealing.

In addition to finding a time window when an event is part of a trend, atotal probability over a specific time period can be obtained. In oneembodiment, the function F can be integrated (e.g. sum counters for timeranges) over the desired time range. In effect, to obtain a probabilitythat an event will occur within a prescribed time period, one canintegrate contributions over all of the relevant key pairs during thetime period. As an example with one key pair, a probability that someonewill perform a certain event (e.g. a transaction) once they are visitingSan Francisco can be obtained by integrating the key pair <SF:KF> overall of the desired time periods. In one aspect, time periods of greaterthan one month may not be relevant if a person never stays in SanFrancisco for that long (which could be identified from a location of aperson's phone or by locations of transactions). One could alsodetermine a probability for a transaction to occur in November in asimilar way.

As an alternative to all of the above steps, one can select a particularevent and a particular time, which can be used to select the relevantpatterns from which the corresponding matrix element can be analyzed. Ifthe tables indicate a desirable likelihood (e.g. relative to thresholdvalues), then a trend can be determined. The probability distributioncan also be analyzed, starting at the particular time, to find astronger trend (e.g. increasing or decreasing probability values), or tofind a trend if one did not exist at the particular time.

In one embodiment, the relevant patterns from which the correspondingmatrix element are selected by creating a set of key pair tables with 1or other non-zero values in the appropriate matrix elements. Thesetables are then multiplied by the saved tables (i.e. known patterns) toobtain the likelihood, effectively filtering out the desired values.Besides a particular time, a time window can also be specified, whichmay cause more than one matrix element in a table to have a non-zerovalue. In this case, the non-zero values can be based on a level ofoverlap of the time window with the corresponding time ranges of thematrix elements.

Referring back to method 800, in step 880, the currently calculatedprobability distribution can optionally be compared to other probabilitydistributions calculated previously. In one embodiment, the previouslycalculated distributions are for the same :KF> event. In this manner, achange in probability at a particular time in one distribution toanother can be determined. This change can be used to determine a trend.For example, the change can be plotted and a trend in the change can bedetermined. The change can be used to predict a trend even when thelikelihood values fall within an expected or average band.

In step 890, a course of action can be determined based on a determinedtrend. Various example actions and determinations are now described.Examples of actions include marketing campaigns, inventory levelsinventory levels (e.g. at particular stores or for all stores), pricing,and store locations. In one embodiment, the future time of the trend andits relationship to the present time can impact the action taken. Forexample, if the time window starts soon, an action that can be performedsoon (e.g. discounting price) can be initiated. Whereas if the timewindow does not start for an extended period of time, an action thattakes longer (e.g. moving inventory or opening a store) can beperformed.

Also, once an event is found to be likely, further analysis can beperformed t o determine whether and how and action is to be performed.For example, a cost of an action, such as the cost of moving inventoryor discounting the price of a product, can be determined as part of acost-benefit analysis. The analysis can also include situations whereinventory levels are high, and thus the product needs to be soldquickly. In one embodiment, the cost of an action can include a possibleloss due to fraud, which can be calculated by comparing a transactionpattern of an entity (e.g. a demographic) to patterns known to befraudulent (e.g. by multiplying tables of the entity against tables of afraud entity). In another embodiment, a profit of an event can bedetermined, e.g., the profit from a transaction in which a trend isidentified. If the profit is high, then a higher cost and lower trendcan be tolerated.

In one embodiment, calculations for the prediction of an event can berun in real time (e.g. within several hours after an event or series ofevents occur). In another embodiment, the calculations can be run asbatch jobs that are run periodically, e.g., daily, weekly or monthly.For example, a calculation can run monthly to determine who is likely tobuy a house, and then a coupon for art, furniture, etc. can be sent tothat person. In various embodiments, prediction of major purchases cangenerally be run in larger batches, whereas prediction of smallpurchases can be run in real-time (e.g., in reaction to a specifictransaction).

In some embodiments, ending events also can be used similarly to predictwhat may happen before the event. Since the occurrence of an endingevent can be known ahead of time (e.g. scheduled for a particular time),the correlated initial events can still be predicted. For example,consumer activity prior to a schedule sporting event can be determined,which may be done, e.g., using tables having negative time ranges withthe ending event as an initial key or with positive time ranges with theending event as a final key. Trends in such predicted initial events canalso be used to determine actions.

Any of the computer systems mentioned herein may utilize any suitablenumber of subsystems. Examples of such subsystems are shown in FIG. 9 incomputer apparatus 900. In some embodiments, a computer system includesa single computer apparatus, where the subsystems can be the componentsof the computer apparatus. In other embodiments, a computer system caninclude multiple computer apparatuses, each being a subsystem, withinternal components.

The subsystems shown in FIG. 9 are interconnected via a system bus 975.Additional subsystems such as a printer 974, keyboard 978, fixed disk979, monitor 976, which is coupled to display adapter 982, and othersare shown. Peripherals and input/output (I/O) devices, which couple toI/O controller 971, can be connected to the computer system by anynumber of means known in the art, such as serial port 977. For example,serial port 977 or external interface 981 can be used to connectcomputer system 900 to a wide area network such as the Internet, a mouseinput device, or a scanner. The interconnection via system bus 975allows the central processor 973 to communicate with each subsystem andto control the execution of instructions from system memory 972 or thefixed disk 979, as well as the exchange of information betweensubsystems. The system memory 972 and/or the fixed disk 979 may embody acomputer readable medium. Any of the values mentioned herein can beoutput from one component to another component and can be output to theuser.

A computer system can include a plurality of the same components orsubsystems, e.g., connected together by external interface 981. In someembodiments, computer systems, subsystem, or apparatuses can communicateover a network. In such instances, one computer can be considered aclient and another computer a server. A client and a server can eachinclude multiple systems, subsystems, or components, mentioned herein.

The specific details of particular embodiments may be combined in anysuitable manner without departing from the spirit and scope ofembodiments of the invention. However, other embodiments of theinvention may be directed to specific embodiments relating to eachindividual aspect, or specific combinations of these individual aspects.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using hardware and/orusing computer software in a modular or integrated manner. Based on thedisclosure and teachings provided herein, a person of ordinary skill inthe art will know and appreciate other ways and/or methods to implementthe present invention using hardware and a combination of hardware andsoftware

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium for storage and/ortransmission, suitable media include random access memory (RAM), a readonly memory (ROM), a magnetic medium such as a hard-drive or a floppydisk, or an optical medium such as a compact disk (CD) or DVD (digitalversatile disk), flash memory, and the like. The computer readablemedium may be any combination of such storage or transmission devices.

Such programs may also be encoded and transmitted using carrier signalsadapted for transmission via wired, optical, and/or wireless networksconforming to a variety of protocols, including the Internet. As such, acomputer readable medium according to an embodiment of the presentinvention may be created using a data signal encoded with such programs.Computer readable media encoded with the program code may be packagedwith a compatible device or provided separately from other devices(e.g., via Internet download). Any such computer readable medium mayreside on or within a single computer program product (e.g. a harddrive, a CD, or an entire computer system), and may be present on orwithin different computer program products within a system or network. Acomputer system may include a monitor, printer, or other suitabledisplay for providing any of the results mentioned herein to a user.

The above description of exemplary embodiments of the invention has beenpresented for the purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdescribed, and many modifications and variations are possible in lightof the teaching above. The embodiments were chosen and described inorder to best explain the principles of the invention and its practicalapplications to thereby enable others skilled in the art to best utilizethe invention in various embodiments and with various modifications asare suited to the particular use contemplated.

1. A method of identifying a consumer as belonging to a particulardemographic, the method comprising: receiving first data associated withfirst transactions of a first entity and second data associated withsecond transactions of one or more second entities; a computer systemidentifying one or more first patterns of the first previoustransactions and identifying one or more second patterns of the secondprevious transactions, wherein each pattern includes a plurality ofvalues, with at least two of the values respectively includingcontributions from transactions corresponding to different time ranges;comparing the one or more first patterns to the one or more secondpatterns; and based on the comparison, determining whether the firstentity and the one or more second entities belong to a same demographic.2. The method of claim 1, wherein the first entity is a first consumerand the one or more second entities are one or more second consumers. 3.The method of claim 2, wherein the first consumer belongs to the samedemographic at less than one hundred percent.
 4. The method of claim 3,further comprising: comparing the first patterns to other patternsassociated with other demographics; and determining whether the firstconsumer belongs to the other demographics.
 5. The method of claim 4,further comprising: defining the first consumer as a linear combinationof the patterns of the demographics to which the first consumer belongs.6. The method of claim 2, further comprising: sending an incentive for afirst transaction to the first consumer, wherein the incentive is sentat a time correlated to when the first transaction is likely for the oneor more second consumers; and wherein determining whether the firstentity and the one or more second entities belong to the samedemographic includes determining whether the first consumer uses theincentive when the first transaction is likely for the one or moresecond consumers.
 7. The method of claim 1, wherein a value of eachpattern corresponds to a likelihood of a transaction occurring within aspecified time range.
 8. The method of claim 1, wherein identifying oneor more patterns of transactions includes: associating one or more keyswith each previous transaction; correlating pairs of previoustransactions, each correlated pair associated with a particular pair ofkeys; and for each correlated pair, determining time intervals betweenthe transactions of the correlated pair; and for each key pair: trackingnumbers of occurrences of correlated pairs having time intervals withinspecified time ranges, the transactions of the correlated pairs beingassociated with corresponding keys of the key pair.
 9. The method ofclaim 8, wherein comparing the one or more first patterns to the one ormore second patterns includes comparing a portion of first patternsassociated with pairs of keys that match with pairs of keys associatedwith a portion of the second patterns, the method further comprising:identifying first patterns associated with pairs of keys that do notmatch with pairs of keys associated with the second patterns, whereindetermining whether the first entity and the one or more second entitiesbelong to a same demographic includes analyzing the non-matchingpatterns.
 10. The method of claim 1, wherein comparing the one or morefirst patterns to the one or more second patterns includes determining adifference between corresponding values of matching patterns between thefirst entity and the one or more second entities; and comparing a sum ofthe differences to a threshold value.
 11. The method of claim 1, whereincomparing the one or more first patterns to the one or more secondpatterns includes: multiplying values of a first pattern withcorresponding values of a matching second pattern to obtain a pluralityof resulting values; and analyzing the resulting values to determinewhether the first consumer and the one or more second consumers belongto a same demographic.
 12. The method of claim 11, wherein analyzing theresulting values is performed with a neural network.
 13. A computerprogram product comprising a tangible computer readable medium storing aplurality of instructions for controlling one or more processors toperform the method of claim
 1. 14. A computer system comprising: one ormore processors; and the computer program product of claim
 13. 15. Amethod of identifying a trend in consumer behavior, the methodcomprising: receiving data associated with previous transactions of anentity; a computer system determining one or more patterns of theprevious transactions, wherein each pattern includes a plurality ofvalues, with at least two of the values respectively includingcontributions from transactions corresponding to different time ranges;determining likelihoods for an occurrence of a transaction according tothe one or more patterns, each likelihood at a respective one of aplurality of different times; and identifying a trend in occurrences ofthe transaction based on the likelihoods at the plurality of differenttimes.
 16. The method of claim 15, wherein the entity is a group ofsimilar consumers.
 17. The method of claim 15, wherein the entity is amerchant or a group of similar merchants.
 18. The method of claim 15,further comprising: selecting one or more relevant patterns from thedetermined patterns based on a product and/or a merchant associated withthe transaction, wherein the likelihoods are determined from therelevant patterns.
 19. The method of claim 15, wherein determining theone or more patterns of the previous transactions includes: associatingone or more keys with each previous transaction; correlating pairs ofprevious transactions; and determining time intervals between correlatedpairs of previous transactions; and tracking the occurrences of pairs ofcorrelated previous transactions having time intervals within specifiedtime ranges for a plurality of pairs of keys.
 20. The method of claim15, further comprising: adjusting one or more characteristics of aproduct being sold based on the identified trend.
 21. The method ofclaim 20, wherein the characteristic includes a number of items of theproduct and/or a price of the product.
 22. The method of claim 21,wherein the number of items is adjusted by changing inventory levels ofthe product at a particular location.
 23. The method of claim 15,wherein identifying a trend in occurrences of the transaction based onthe likelihoods at the plurality of different times includes determininga likelihood above an upper threshold value or below a lower thresholdvalue.
 24. The method of claim 15, wherein determining likelihoods foran occurrence of a transaction according to the one or more patternsincludes determining a probability distribution as a function of timefrom the one or more patterns, and wherein the trend is identified fromchanges in the probability distribution from one time to another. 25.The method of claim 15, wherein determining likelihoods for anoccurrence of a transaction according to the one or more patternsincludes determining a probability distribution as a function of timefrom the one or more patterns, the method further comprising:determining one or more other probability distributions from one or moreother patterns associated with the entity, wherein the other probabilitydistributions are determined at calculation times different than theprobability distribution; calculating a difference between theprobability distribution and the one or more other probabilitydistributions, wherein the trend is identified based on the difference.26. A computer program product comprising a tangible computer readablemedium storing a plurality of instructions for controlling one or moreprocessors to perform the method of claim
 15. 27. A computer systemcomprising: one or more processors; and the computer program product ofclaim 26.